A service-oriented architecture (SOA) is essentially a collection of services that communicate with one another. The communication can involve simple passing of data or can involve two or more services coordinating a task. In the SOA paradigm, the relationship between a service consumer (client) and a service provider (server) is generally considered to be loosely-coupled, in that no state is assumed to be maintained. This scheme, therefore, calls for means of communication which requires that each message (or request) sent from a client to a server contain instructions for performing a task and also any information needed to perform the task. The server performs the function described in the request, and returns a reply message. In this way, the server provides a service in which a specific functionality is available on demand.
Web services, as examples of SOA, are characterized by an ability to provide interfaces to services. The interfaces are typically built using open standards such as XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol), and WSDL (Web Services Description Language), and make use of an internet protocol, such as the HTTP (Hypertext Transfer Protocol), for communication. Generic interfaces provided by web services have been widely adopted due to ease of implementation, however, performance or efficiency concerns of web services generally have not been addressed. Additionally, web services do not provide a basis for a client developer to automate common tasks, which could be highly useful for complex web services that offer rich functionality.
When depending upon web services as an application interface performance can be a problem as almost all communication occurs through, for example, exchanges of text-based messages over the web. While using web services as an application interface provides for accessibility and interoperability between two or more applications, such an architecture requires a complete round-trip—i.e., a request to a server followed by a reply to a client—for each individual request. In cases where a client application repeats an operation several times or where a client performs a series of commonly used operations a round-trip for each request generally increases the time spent on the overall operation.
A useful characteristic of web services is the ability to abstract functionality into smaller services, as this allows for fully self-contained requests to the service. This characteristic has the effect of decreasing the interdependence of a client and a server within a client-server relationship, as state need not be maintained on either client or server during the execution of a request. This is an essential feature as the web itself is a volatile medium and requests cannot be guaranteed to always reach a destination. A negative aspect of abstracting functionality into smaller services, however, becomes apparent due to increased time for a complex web service to perform a variety of operations that are used in a complementary manner with one another. In a case where a client application must implement a pre-defined sequence of operations (each corresponding to a request to a web service) that constitute a single piece of business logic, minimizing the number of round trips to the server would not only improve performance, but also permit a client developer to export the business logic to the server side by creating a batch request to represent the business logic.
A primary drawback to creating any sort of automation of web service requests is the necessity of having to maintain state in the relationship between a client and a server. In other words, in order to implement a system in which multiple operations can be performed sequentially to form an abstraction for larger operations, state must be introduced at some point on either the client or the server to maintain the request sequence and data flow between requests. Maintaining state, however, is contradictory to the intent and purposes of SOA and web services and is, therefore, not a desirable solution.
Accordingly, what is needed is a mechanism for providing stateless automation for web service requests that is compatible with the SOA paradigm and web services. The present invention addresses such a need.